One option is a release management checklist. The checklist should outline the process functions and responsibilities in roughly chronological order. When your team looks at the checklist, they should be able to quickly establish what step they are on and what their role or responsibility is. Another option is to create a release workflow. A listing of current news releases published by the IRS. IR-2021-04, January 6, 2021 — The Treasury Department and the Internal Revenue Service issued guidance today allowing deductions for the payments of eligible expenses when such payments would result (or be expected to result) in the forgiveness of a loan (covered loan) under the Paycheck Protection Program (PPP).

Each GnuCash release involves a number of steps for the release manager. This page is intended to gather these steps for the program, while the Documentation Release Process is separated.

• 2Release Process
• 6Flathub package
• 7Git housekeeping after a release
• 8GnuCash Website
• 10GnuCash Wiki
  • 10.1Update Release Version
• 16New Major/Minor Version

Commit Policy

Check Git#Branching and Merging.You'll need write access to https://github.com/flathub/org.gnucash.GnuCash/. Ask https://github.com/orgs/flathub/people.

Release Process

Notes

• Where relevant, the process below assumes that the primary git repository is configured as a remote called 'upstream'. If you have configured it under another name, please adapt the commands below accordingly.

Dependency Updates

They are ideally done a few days before a release and verified in the nightlies.

Bundle specific

Flatpak

Gnome runtime available versions are listed by:

Source preparation

• Check out Git branch you wish to release. Typical candidates are master, maint or any maint-X.Y. For example
• Check translations at the Translation Project Gnucash page for updates and
  1. apply any that haven't been already committed, e.g. as suggested in translationprojects maintainers page.
     • The translation project recommends using

     But that will replace newer translations from direct contributors with old translations no longer supported by the translation project.

     • Another approach is to substituting the last version of GnuCash for '2.6.4'. This does the same except that the old translations have been msgmerged with the last release's pot file making them appear newer than they are.
     • The safest approach is to look at TP Latest and download only the files which have updates since the previous release; for extra confidence examine the 'PO Revision Date' header in each file; it should change if there are real translation updates.

     Question

     How about using method 3 for the release notes, but get also the merged-only files for statistical purpopse? msgfmt --statistics would else deliver wrong results.

  2. If there are new languages, merge them into TP_LINGUAS in po/CMakeLists.txt.
  3. Next, check syntax and get the statistics:
  4. Check the new files from TP for common mistakes from Translation#Committers.

  Note

  These should probably applied to the oldest branch for which you expect do do releases still which may not be the branch you want to release now from. If this is the case apply them to the proper branch (eg maint) and merge upwards to your branch (eg master).

• If you are about to release from master you should verify that master is a superset of maint. You can do this by running the following command This command should not list any commits. If it does, checkout master and merge maint into it

  Note

  The same check should be performed when releasing from maint and there is an older maint-X.Y branch on which commits still happen.

• Verify that current branch can build a distribution tarball, compile, and test it fine:

In this step, some files might have been changed such as POTFILES.in, which can then be committed before actually incrementing the version number. However, some of the test data files might also have been changed due to 'make check', but those changes should not be committed.

• Update the version number of the project(gnucash VERSION)
  • in the root CMakeLists.txt
  • and on major releases in README Line 4.
• Run to extract the bugs fixed and other changes. There are plain text and HTML sections for the NEWS file and for the web page, Github, and email announcements. The bug list can be copied in to each as-is, the other section should be copied and then edited to leave only changes that impact users or contributors. Translation updates should be removed and the languages updated listed separately.
• If this is the first release of a calendar year:
  • Run make, which should update the ChangeLog file now.
  • If you are building out of tree, copy the updated ChangeLog from your build directory to your source directory.
  • Rename ChangeLog to ChangeLog.YYYY with YYYY being the previous year.
  • In the root CMakeLists.txt:
    • Add ChangeLog.YYYY to the gnucash_DOCS variable,
    • Find the rule to generate the ChangeLog, update the '--since' parameter to the start of the current year.
  • Add the new ChangeLog.YYYY to git.
• Commit changes to NEWS to the git repository.
• Push all your changes to upstream:
• Tag the new release.

For example:

Don't push the tag yet! Releases should be atomic, so proceed to building the tarballs and distribution bundles and preparing the release notes and announcements. Push the tag immediately before publishing the release. If for any reason while building tarballs you discover a problem that needs fixing, or if someone pushes a commit that you want to add to the release, you can simply re-tag the release (git tag -afm 'Tag 3.4'3.4) to the latest commit and make new tarballs and bundles, but you can do that only if you haven't pushed the tag.

Source tarballs

• Checkout the release tag from git. Either clone or clean your git repo here to avoid packaging unreleased changes ! For example:

or, while inside your local repo

Warning: As Eclipse user do not use the -x flag or all project information will be lost. Or add -e /.project -e /.cproject -e /.autotools -e /.settings/

• Now run

This should generate two tarballs, one bzip2 compressed and one gzip compressed. Using ninja distcheck performs several checks on the distribution before making the tarballs, then decompresses one of them, builds it, and runs ninja check on the results which ensures that everything is properly packaged for distribution. If you used your regular repo you'll want to clean it again after uploading the tarballs.

Documentation

Now make a documentation release using the same version number as you set above for GnuCash. See Documentation Release Process for the procedure.

Windows Executable

The creation of the tag in the first section will automatically trigger the build for the Windows Executable in the next nightly build. The resulting executable can be downloaded the day after from http://code.gnucash.org/builds/win32.

Perl version

Check http://strawberryperl.com/ for the recommended version and update strVersion in extra_dist/getperl.vbs.

From PR#15

• Can we drop custom language files, because they have become official?
• Are there updates for unofficial translations?

MacOS Executable

This package is usually created by John Ralls using this procedure .

Sourceforge file uploads

All the above build targets should be uploaded to Source Forge.

• Make SHA256 digests of the two tarballs and the three installer packages, e.g.

• Log in on the [Source Forge GnuCash website]
• Go to the Project Admin -> File Manager section
• Create a new directory for the release, either under gnucash (stable) or gnucash (unstable). Mark it 'staged' in either the creation or the info dialog.
• Upload the files created above to this directory.
• If this release is the latest stable release, edit each file's metadata by clicking on the 'i' button. For each file indicate for which platforms the file is intended (.exe file on Windows, .dmg file on Mac OS X, source tarball on all other targets). Sourceforge will use this additional information to present a direct download link to the latest release on the user's native platform.
• When everything is ready, open the info dialog for the containing directory and clear the staged check-box. Note that if the release runs into problems that take more than 3 days you may need to renew the 'staged' flag.

Flathub package

Steps to run in a clone of Gnucash's gnucash-on-flatpak repo

1. Follow https://github.com/Gnucash/gnucash-on-flatpak/blob/master/README.md to set up a gnucash-on-flatpak build environment.
2. For stable releases use the master branch; for unstable releases use the unstable branch.
3. Do a release build in that build environment by running 'build-package.sh -r4.4 -c4.4 -d4.4' (+1 of course)

   Notes

   • The -r parameter stands for revision. It's the primary parameter to tell the build script what to build and can be any single git revision specifier, like a branch, commit hash or tag. In the context of a release, only the tag format should be used. That will trigger a different build procedure than a branch or commit hash: in that case the build procedure will download tarballs from sourceforge for the flatpak generation instead of cloning git repositories.
   • The parameters -c and -d also only make sense for release builds and are only required when the tags for code and documentation differ from the sourceforge file directory. In that case set -r to whatever the sourceforge directory name is for the release tarballs (for example 3.8), -c to the code tag to use (for example 3.8b) and -d to the documentation tag to use (for example 3.8). You can omit -c or -d if they are the same as -r, but always specify at least -r (as that will otherwise default to maint resulting in a development build or a tarball not found error).
4. The release build will generate/update 3 files in the base directory of the gnucash-on-flatpak repository
   • gnucash-source.json
   • gnucash-docs-source.json
   • gnucash-extra-modules.json

Steps to run in a clone of flathub's org.gnucash.GnuCash repo

1. Clone https://github.com/flathub/org.gnucash.GnuCash/
2. For stable releases use the master branch. For unstable releases use the beta branch.
3. Copy the above three files to this clone and commit as 'Update to upstream gnucash x.y'
4. Run command git log --date=short --format='<li>%ad - %s (%an)</li>' 3.8-10..HEAD. 3.8-10 should be replaced with the most recent tag in the flathub repo.
5. Use the result of this command to update gnucash.releases.xml

   Note

   For a fresh release the releases file should be reduced back to only one release. It tracks changes made to the flatpak that are outside of the gnucash release cadence (like rebuilding with a newer aqbanking version). If this is a rebuild due to an updated dependency, add an additional release instead.

6. Open file org.gnucash.GnuCash.json and edit the build rule for gnucash. In particular update the GNUCASH_BUILD_ID number to reflect the current version.

   Note

   For a fresh release the build id is just 'Flathub <release.number>'. However as mentioned before the flatpak may be updated more frequently than gnucash itself. In that case the build id would become 'Flathub <release.number-pkgnumber>', where the number is obtained by running git describe --match <release.number> (note the absence of pkgnumber here) without the commit hash.

7. Commit gnucash.releases.xml and org.gnucash.GnuCash.json as 'Package gnucash <release.number-pkgnumber>' with or without -pkgnumber depending on whether it's a fresh gnucash release or not.
8. Tag this commit using git tag -a -m 'Package gnucash <release.number-pkgnumber>' <release.number-pkgnumber>. Again with or without -pkgnumber depending on whether it's a fresh gnucash release or not.
9. Push all of this upstream.

From there on you can follow the flathub build process here:

Stable releases

https://flathub.org/builds/#/apps/org.gnucash.GnuCash

Unstable releases

https://flathub.org/builds/#/apps/org.gnucash.GnuCash~2Fbeta

Git housekeeping after a release

All releases

If any changes were committed during the release steps above, merge these upwards to the other upstream branches. For example if you committed something to maint, merge maint into master:

Expect merge conflicts here for the changed version number and the different documentation links in README. This is normal and the conflict should be resolved by keeping the version number in master. There may be other merge conflicts. Evaluate them and fix them accordingly.

If the release was from an older maint-X.Y branch, merge these changes into maint and then merge maint into master. Expect the same version number conflict during the merges.

A major release

A major release is the first release to bring new development features to the users. This is shown by a jump in the version number (for example from 2.6.x to 2.8.0), and signifies the start of a new major development cycle.

This means the branches in our repository have to be reshuffled. The release is done from a commit on the master branch. This commit should now become the HEAD commit for the maint branch because maintenance should now happen from there on. At the same time it may be necessary to keep up maintenance to the previous major series, so this should now get its own branch.

In git:

The first command creates a maintenance branch for the old stable release series. The subsequent commands move maint to where master is now. If the latter command fails there are commits on the maint branch that didn't get merged into master. This should not happen if the earlier steps were followed to verify master is a superset of maint.

GnuCash Website

Note that gnucash-htdocs is a pure git repository. In order to update the website you will hence have to follow the instructions on our Git wiki page to prepare a local gnucash-htdocs repository with commit access to the primary repository on code.gnucash.org. Be sure to follow the committer instructions for pure git repositories on that page !

Adding the announcement text

1. Checkout the master branch and make sure it's up to date
2. Go to the news files
3. Copy the last release newsfile. The filename format is usually YYMMDD-<releasenumber>.news. For example:
4. Replace the old release numbers in this file. Note that release announcements usually contain two release numbers: the current release and the previous release. Both of them should obviously be replaced. The order to execute the following commands is important! For example:
5. Open the new file in your favorite editor. Using the NEWS files you created for GnuCash and GnuCash Documentation as a basis, revise the announcement to reflect the changes in this new release. Check for
   • Announce of Feature/String Freeze for the next release

   This will help to polish the GUI and review for I18N issues.

   • Declare start/continuation of Feature/String Freeze for this release

   This will give translators time to complete.

6. Tidy the file.
7. Add the new file to revision control

Updating the release number for the download pointers

After processing #New Major Release, the release number should be added to the website configuration script. This ensures all download links are appropriately updated.

• Edit the file gnucash-htdocs/externals/global_params.php. The first few lines in this script set various release numbers: latest_stable, latest_unstable and variants thereof on Windows and MacOS. Adapt these parameters as needed.

First Release of the Year

Update the copyright end date in externals/footer.html.

New Major Release

download.phtml

Copy 'Last version for <OS><Version>' elements from <divid='previous'…> to <divid='historical'…> and replace there then '$old_stable*' by '$last_*' variables. On demand create them in externals/global_params.php.

docs.phtml

needs a new section in $older<n> as long as we do not convert it in a loop with version dependend LANGs.

viewdoc.phtml

needs adjustemt in

robots.txt

Disallow: /docs/v<ancestor(4)> /

Commit the changes.

Finally, all these changes to the website should be committed. From the base directory:

The last command will take care of updating the live website.

GitHub

Set up a new release on GitHub:

1. Go to The GnuCash releases page and press the 'Create New Release' button.
2. Enter the release tag in the tag box. It should already exist.
3. Type the title 'GnuCash <releasenumber>' into the title box, substituting the correct release version.
4. Copy the release news file from 'The GnuCash Development Team proudly announces' through the Documentation section and paste it into the 'write' box. Use the Preview tab to check the result.
5. Drag or select the Mac and Windows installers into the binaries box.
6. Click the Publish Release button when everything is ready.

N.B.: This may not work on some browsers or with certain security features (NoScript is a suspect). If it fails to upload the files try a different browser.

GnuCash Wiki

Update Release Version

Since 2018-04 we use Templates to maintain the versions. The previous manually updated pages are only mentioned for cross checking:

New Packages

New Minor Stable Release

New Beta Release

Note

Currently it is unused.

Fixme

Will it be sufficient or should we have current and next?

New Major Release

Tip

To find all appearances, in a template see What links here(?).

Policy Change

This are constants until we change the policy of versioning.

Release Schedule

Add the actual release date to Release Schedule.

Translation Status

If the branch for translations switches, adjust Translation Status.

Mailing list announcement

Send the same announcement to the following lists:

• BCC gnucash-devel@gnucash.org
• BCC gnucash-announce@gnucash.org

Question

Should we BCC also the user lists in other languages?

To do so, you have to be subscribed to the mailing lists. Then I found it easiest to copy the release announcement from my web browser into a new mail message (Kmail). In kmail this converts the html in a reasonably clean plain-text message. Some further minor cleanup may be necessary. This works in Apple Mail as well.

The bit at the bottom about downloading from Sourceforge loses the links, so replace it with:'The latest binaries and tarballs can always be downloaded from the upper right corner of http://www.gnucash.org.'

The BCCs are to prevent reply-alls from being copied to those lists, though they cause the email to get held for moderation.

Translation Project

Email

• a link of the release tarball to coordinator@translationproject.org.
• If NEW_LINGUAS in po/CMakeLists.txt is not empty,
  1. inform them to mark that languages as external,
  2. move the languages into GC_LINGUAS.

IRC

Update the topic of irc://irc.gnome.org/gnucash:/TOPIC #gnucash Free GPL Personal and Small Business Accounting || Please don't ask to ask, just ask and wait! (Possibly a few hours!!) || publicly-logged channel || latest stable: <version> || www.gnucash.org

Bugzilla

After logging in

• Add the new version number and eventually

for at least Gnucash and Documentation.

Promotion

Verify

• http://freshcode.club/projects/gnucash gets updated or adjust it. The autoupdate section is in the lower part of http://freshcode.club/submit/gnucash. It is also mirrored as https://freshfoss.com/projects/gnucash.

• https://www.facebook.com/Gnucash: CMarci once had set it up. 23 May 2018 21:01:29 +0200 jralls became the owner.

The culmination of each development cycle is the release of a new series with a new minor, and perhaps a new major, version number. Preparation for this release is typically a six-month alpha/beta release project with some special milestones.

Version Numbers

GnuCash uses a two-part version numbering system because the Major numbers in the three part system changed so rarely as to be useless. The major number will increment with 'major' releases, those which include significant new features or incompatible changes. We expect to do major releases every 2-3 years. In between, minor releases will contain bug fixes and minor new features; database schema and exposed API will not change. Unstable releases will use minor numbers beginning with 900.

Before the release of GnuCash 3.0, we used a three-part version number: Major, Minor, and Micro. Major version numbers were changed rarely and only after major architectural changes to GnuCash. Minor versions were changed when preparing a new stable series from the development, or master, branch. Unstable releases were given an odd minor version, stable releases an even minor version number. Micro version numbers were assigned sequentially to each release in a series.

Freezes

In order to allow time for thorough testing and localization, it's important to set aside some development activities during the run up to a stable release. The dates that those activities stop are traditionally called freezes.

Feature Freeze

No new features or significant architectural changes should be committed after this date to ensure that there's adequate time for the more adventurous users who act as our testers to try everything out and provide feedback.

String Freeze

No new user-visible strings should be added after this date in order to allow translators time to finish their work by the final release date. The Translation Project requests at least two weeks, but practice suggests that a month or more is better before a major release.

Suggestion

Announce the string freeze one release in advance. This would allow some GUI cleanup, check for I18n issues, join similar strings ...

Code Freeze

Slightly misnamed, this means that only code fixing critical bugs and of limited scope, so that it's unlikely to cause regressions in other parts of the program, should be committed.

Release Schedule and Milestones

• Monthly test releases should begin 6 months before the target release date.
• The team should determine dates for feature and string freeze, and publish them on the Release Schedule.
• the Translation Project Coordinators should be notified of the first release after string freeze by emailing a link to the tarball to coordinator@translationproject.org.
• After Code Freeze test release frequency should increase to weekly. The announcements for these releases should inform testers that they are release candidates.

English ; Español ; eesti keeles ; français ; Português do Brasil ; 简体中文 ;

• 4Major new features
  • 4.1Installation
  • 4.2Package management
  • 4.4Base system
  • 4.5Packaging
  • 4.6Graphical environments
• 5Upgrading from Mageia 2
  • 5.1Upgrading via the Internet
• 6Known issues

Mageia has two distinct installation media types:

• DVD ISO and Dual-arch CD ISO, which use the drakx traditional installer and
• Live DVD/CD ISO, a live ISO which can be used to preview the distribution and also later be used to install Mageia on your hard drive.

For more information have a look at the installation media page.

You will always find the download info on the Mageia download page; direct (ftp and http) and BitTorrent downloads are available.

The Mageia software sits in three different repositories/media, depending on the type of license applied to each package. Here's an overview of those repositories:

• Core: The Core repository includes packages with free-open-source software, i.e. packages licensed under a free-open-source license, the set of the 'Core' media along with 'Core Release' and 'Core Updates' are available by default.
• Nonfree: The Nonfree repository includes packages that are free-of-charge, i.e. Mageia may redistribute them, but they contain closed-source software (hence the name - Nonfree). For example this repository includes nVidia and ATI graphics card proprietary drivers, firmware for various WiFi cards, etc.
  The Nonfree media set is added by default but not enabled by default.
• Tainted: The Tainted repository includes packages released under a free license. The main criteria for placing packages in this repository is that they may infringe on patents and copyright laws in some countries, e.g. multimedia codecs needed to play various audio/video files; packages needed to play commercial video DVD, etc.
  The Tainted media set is added by default but not enabled by default, i.e. it's completely opt-in; so check your local laws before using packages from this repository.
  This repository is only added for the convenience of the users. This repository is to Mageia what PLF is to Mandriva users or RPM Fusion is to Fedora users.

Installation

Stage 1

• The first stage of the installer automatically passes the correct URL to stage2 if it was provided.

eg http://foobar.com/mirrors/mageia/3/ instead of http://foobar.com/mirrors/mageia/3/x86_64

• The installer can now create and install to a btrfs file system, however to boot correctly a separate ~200MB ext2 partition with the mount point /boot must be created during the partitioning step.

• It now uses kmod for loading modules

• A bug was fixed in kmod which would cause the installer to load an incorrect driver for some hardware due to kmod not enforcing module ordering (mga#5833).

List of all change since Mga2

Stage 2

• Hardware support
  • Tokenring is no longer supported.
  • support was added for a ton of recent hardware
• media
  • It is now possible to enable nonfree and tainted media during install. Proprietary drivers and/or non-free firmware can now be installed during installation. The user is asked whether to keep non-free packages during installation via a simple checkbox. Moving the mouse above the media shows a description of what each contains.
  • nonfree media is pre-selected if we detect hardware that will not work without non-free firmware
  • when adding update media at the end of install, all media are now installed as updates that might require packages from the full sources (DVD is only a subset)
• The installer can now write a debug file to a USB key formatted as NTFS instead of FAT (mga#5685).
• The installer has been updated to include the latest kernel/rpm/perl/pango/x11-server.
• Storage
  • whereas drakx integrates well in most virtualized OSes, it finally supports installing on XEN paravirtualized disks.
  • Resizing NTFS works again (it was broken by the switch from ntfsprogs to ntfs-3g)
  • The 'acl' option is only allowed for extX & reiserfs
  • The minimum size for auto spliting the /home file system is now 12Gb instead of 8 in case of simple partitioning, or 10Gb instead of 7 to 10Gb if /usr is split off (e.g.: servers)
  • It is now possible to choose btrfs in normal mode
• GUI:
  • the GUI has been refreshed and now uses the Oxygen theme
  • the help has been vastly improved
  • text size of the help and of the updates installation is the same as the installer one
• support for xguest was disabled
• package groups
  • An 'unselect all' button has been added when one chooses to pick package groups, allowing a faster minimal installation.
• Grub2 can now be installed at the summary step, it can also be installed in a partition. However, please see the errata for information on how to multi-boot into the system. Integration in drakboot is only partial, if you feel that you need to customize the menu then please read /usr/share/doc/grub2/README.Mageia for the native grub2 techniques, or you could maybe try grub-customizer.
• various improvements:
  • auto install: xdm install is now non-interactive
  • fixed installing of minimum system prior to the set up network media
  • installation errors are displayed only once at the end instead of stopping the install for each error with a popup.
• ...

List of all changes since Mageia 2.

Debugging

It is now possible to rebuild stage 1 and stage 2 packages with a debug option in order to have better environments for debugging the installer.

Rescue

• Rescue mode will select the most recent version of Mageia when several Mageia instances have been installed. It now also offers to pick the one to rescue.
• It will refuse to repair an incompatible installation (eg: 64 bit OS with a 32 bit rescue).
• It detects software RAID setups better.
• It is able to rescue systems with SMB mount points.
• It includes a script to simplify the grabbing of journal logs for bug reports.
• It drops unmaintained support for KA (clustering)

Package management

RPM has been upgraded to 4.11.

Urpmi has been refactored and cleaned.Various bugs have been fixed:

• urpmi used to download noarch packages twice when using the --download-all option on 64-bit machines because they are in both 32 and 64-bit repositories (mga#4867)
• urpmi no longer silently fails with exit status 0 when:
  • package installation fails due to any conflicts
  • unselecting package
  • failing to install some (but not all) packages
• urpmi now looks again for missing requires of updates in the regular media instead of only looking in update media (mga#2317)
• urpmf and urpmq now work as user with the --use-distrib option (mga#1225)
• urpme will no longer offer to remove DKMS modules for the current kernel (mga#5092)
• gurpmi:
  • gurpmi will upgrade glib, gtk & perl-{Glib,Gtk2} bindings as priority upgrades prior to a restart (mga#5066)
  • gurpmi now wraps some huge debug messages and uses a scrollbar in such cases (mga#5118)

Various enhancements have been made:

• urpmi now has basic support for --downgrade.
• urpmi now has basic support for delta packages.
• urpmi.addmedia now enables nonfree/tainted media if such packages were previously installed
• (g)urpmi reports removed packages (e.g.: older versions when upgrading) (previously it seemed to be stalled)
• urpmi now detects I/O, unpacking and scriptlet errors
• urpmq without parameter does not search any more with fuzzy matching, you have to add explicitly the argument -y.
• gurpmi:
  • improved layout
  • better information about disk usage
  • errors summary is displayed at the end instead of showing a popup for each one
  • errors don't popup in automatic mode

List of all the change since Mageia 2.

API change

The --repackage option has been removed (it had not worked since rpm-4.6 was introduced in 2009).Repository metadata can now be compressed with xz instead of gzip.

Security

Urpmi will now warn:

• when a medium has no signing key;
• about unsigned packages from media without signing keys;
• when signature checking is disabled per medium.

The 'download-all' option is supported in urpmi.cfg as opposed to being available only from the command line.

Graphical package manager

Rpmdrake was not properly highlighting the latest changes in package changelogs when they used Epoch.

Updates were sometimes wrongly deselected when clicking on 'New dependencies'.

The --merge-all-rpmnew option is slightly faster. It now also considers all config files, including those outside of /etc.

Rpmdrake now displays a global progress bar when updating, installing or removing packages instead of one progress bar per RPM transaction.

List of all the change since Mageia 2.

Tools

Quite a lot of bugs were squashed.Some notable features:

• Installing kernels had been made safer.
• Harddrake will install ethernet/wireless packages when a new device is detected, which helps quite a lot for Broadcom devices.
• Mcc now finds NFS servers where it failed to do before in some environments.
• Bubble notifications were disabled in net_applet because of a segfault in GNOME's libnotify (mga#9102).
• Autologin is now supported with lxdm and slim too (#3715)

Base system

kernel

• Mageia 3 ships with kernel 3.8.13

systemd

• Mageia 3 comes with systemd 195

GRUB

• Mageia 3 still comes with GRUB as default, however you can install GRUB2. integration is now available in installer and some drakxtools.

File systems

• OverlayFS is now available and used to build live CDs

Perl

• Perl has been upgraded to 5.16.3 and all perl packages have been rebuilt and/or updated

Ruby

• Ruby has been upgraded to 1.9.3, and most of the packages have been rebuilt.

journalctl

• Journalctl is now used as default. You can still install rsyslog if you want logs on tty12 or syslog/user/access/messages logs. draklog has not been modified to deal with journalctl so you will need to have rsyslog installed to use it.
• To be completed

Others

/usr move

• /usr move: main goal is to provide an easy way to mount most of the installed operating system files read-only during normal usage.

Also make it easier to take snapshots (when combined with btrfs or lvm) or share it over the network.

Grub2

• Grub2 is now available for the first time in Mageia and may be selected during installation or later using: Mageia Control Center -> Boot. To test grub2 while still using grub legacy please see /usr/share/doc/grub2/README.Mageia

Note:If grub2 is installed 'to a partition' during installation please read the Mageia-3 errata for more help.

Packaging

Package compression

Packages are now compressed as xz instead of lzma

Easier debugging

By default, minimal debuginfo is installed in order to increase the quality of bug reports and allow easier support for profiling and userspace tracing. Developers will receive better bug reports by default, without users having to enable debug media and install big debug packages.

It will also make system-wide profiling, userspace dynamic probes and casual debugging easier.

RPM groups

The Mageia package groups have been reorganized to improve clarity and for easier browsing in rpmdrake and during installation.

Mass rebuild

Mass rebuild has been completed. The 10,500 source packages were rebuilt in three days on four nodes. Thanks to our packagers, we are close to having 100% rebuild success.

This will improve the quality of Mageia 3 and also post-product support (bug or security updates), won't need to spend time fixing stuff that should already work.

Graphical environments

KDE

KDE 4.10.2.

• Upstream configuration

Starting with KDE SC 4.7 we are providing an additional package name, vanilla, in order for an end user to simply use an upstream configuration for desktop and applications. You simply need to install the vanilla-kde4-config package via rpmdrake or via urpmi like this:

urpmi vanilla-kde4-config

GNOME

GNOME environment is also provided. Currently 3.6.

LXDE

LXDE version 0.5.5 is available. LXDE is a desktop environment intended to be lightweight, fast, and energy-efficient.

XFCE

Xfce 4.10 with various (bug) fixes mainly from upstream.

Available at install behind the 'other desktop' checkbox of the classical iso.

Enlightenment

The e17 release of the Enlightenment desktop environment is available in the Core repositories.

RazorQt

Beta 3 comes with RazorQt v. 0.5.2: 'Razor-qt is an advanced, easy-to-use, and fast desktop environment based on Qt technologies. It has been tailored for users who value simplicity, speed, and an intuitive interface. Unlike most desktop environments, Razor-qt also works fine with weak machines'.

Qt

• Qt 4.8.4

• Qt 5

• QtCreator 2.6.1

Office apps

Games

Steam for linux is now available in the repositories.

Education

Computer Assisted Music

Audio and MIDI Connection Kit

• JACK JACK 1.9.8 (jackit) and qjackctl its GUI (version 1.9.9 may be provided as update)
• lv2 lv2 (version 1.2.0) a plugin standard for audio system (the 1.4.0 version may be provided as update)

Multitrack audio recorder

• Ardour Ardour3 final release is now available (besides Ardour2) with lv2 interface

Instruments

• aeolus aeolus a church organ emulator
• Bristol Bristol (a vintage synthesizers emulator) is available with Menu items for each synthesizer
• Linuxsampler Linuxsampler 1.0 and Qsampler and gigedit (a sample editor) are available
• Yoshimi a software synthesizer version 0.0.60 (version 1.0 may be provided as update)

Sequencers

• Rosegarden Rosegarden 12.04 (just released 13.04 version may be proposed as update)
• Qtractor Qtractor 0.5.6 (just released version 0.5.8 may be proposed as update)

Score editors

• Lilypond Lilypond 2.16 (last stable edition)
• Musescore Musescore version 1.2 A GUI for Lilypond (just published version 1.3 may be provided as update)
• Rosegarden Rosegarden is a score editor too !
• denemo denemo 0.9.6 (just released 1.0.0 version may be provided as update)

Software Development

• OCaml is now in version 4.00.1, with more than 150 libraries
• Harbour Version 3.0 with QtContribs and pre-built HbIDE.
• GnuRadio Version 3.6.4.1

Please read also the known issues.

Upgrading from Mageia 2 is supported, and has been fine-tuned over the past few months, so it should work. But as always, it is very advisable to back up any important data before upgrading and make sure you have made all updates of Mageia 2 (such as rpm and urpmi). Upgrading from Mageia 1 or another distribution is not supported.

There are several ways to upgrade from one of the previous Mageia releases:

Warning: Upgrading an existing install using a LiveCD is NOT supported due to the livecd image being copied 'as is' to the target system.

Upgrading via the Internet

The Mageia update notification applet, Mageia Online, will notify you that a new Mageia release is available, and ask if you wish to upgrade. If you agree, the upgrade will be carried out from within your Mageia installation without any further steps being necessary.

If you have disabled the applet or it is not automatically running for some reason, you can upgrade manually either using the GUI (mgaonline) or the CLI (urpmi). Both methods are outlined below.

First make sure you have the latest updates for your currently running release prior to upgrading. Because of the complications of the usrmove, a newer version of mgaonline is required to recognize the new version and step you through the upgrade process. You must therefore update mgaonline first. The new mgaonline package will itself install the mageia-prepare-upgrade package.

Upgrading online, using mgaonline (GUI)

As noted above you must have the updated mgaonline installed.

The new mgaonline should inform you that a new release is available and will automatically tell you that preparation is required before continuing. It will then:

• Install the package mageia-prepare-upgrade
• Instruct you to reboot and select the 'Mageia 3 Upgrade Preparation' entry in your bootloader (todo: should we use rebootin here?)

If you do not see that mgaonline notifies you that there is a new release, check your options with mgaapplet-config

Or

su

mgaapplet-upgrade-helper --new_distro_version=3

It will notify you of the availability of the new Mageia 3 distribution, configure Mageia media sources and start migration. Again, please ensure you have the updated mgaonline installed before undertaking this stage.

Upgrading online, using urpmi (CLI)

• Before making any changes to your configuration, ensure you have all packages up-to-date and then install the mageia-prepare-upgrade package.

• Once installed, reboot your computer and select the 'Mageia 3 Upgrade Preparation' boot option.

• After rebooting and confirming that the usrmove has completed successfully (check via ls -l / that /bin and /lib etcetera are symlinks to /usr/bin and /usr/lib) you can continue.

• Remove all of the existing media sources on your system by executing this command as root in terminal:

su

urpmi.removemedia -a

• Add the Mageia online sources, either:
  • Using the MIRRORLIST method (which will select a mirror automatically based on your geographical location):

su

urpmi.addmedia --distrib --mirrorlist http://mirrors.mageia.org/api/mageia.3.$ARCH.list

(Where $ARCH is either i586 or x86_64)

• • Using a specific media mirror:

su

urpmi.addmedia --distrib <mirror_url>

You can get the mirror_url using the Mageia mirrors web application

• Finally start upgrading:

su

urpmi --replacefiles --auto-update --auto

• It's best to run the above command twice as in the first run some packages may be downloaded but not installed.

Using the Mageia 3 DVD to Upgrade

You can use the Mageia 3 DVD to do clean installs but also to upgrade from previous releases.

To upgrade:

• Download the ISO from the Mageia download page and burn it on a DVD, or dump it on a USB stick, for more details have a look at this Available installation media article
• Boot the DVD and select 'Install Mageia 3' from the GRUB (the bootloader) menu
• Select the upgrade option.

It is recommended that the online repositories be set up during the upgrade as the DVD only includes a subset of the complete set of Mageia online repositories.

Moreover, it is possible that Mageia 2 may have received an update to a later version of software than that available on the ISO. When this happens, the upgrade may fail to complete. Since, at the time the ISO's are tested it is impossible to anticipate which Mageia 2 packages may be updated in the future, offline upgrades (i.e. upgrades attempted without setting up the online repositories) are not supported.

• New Release Check Procedure Online

On the first reboot use the command 'urpmi --auto-update' to make sure all packages were updated.

See Errata page

Bug reporting

• New Release Check Procedure Regarding

You can find our bugzilla here, but please read the Errata before reporting any bugs. If you don't already have a Mageia account, you can create one at https://identity.mageia.org/. If you don't know how the procedure works, please read how to report a bug first.

• New Release Check Procedure Requirements